[Feature] Add Neon Launchpad DB Provisioning.
Is your feature request related to a problem?
Memori now has a provisioning pattern for BYODB support through TiDB Zero. The next logical provider to support is Neon Launchpad for PostgreSQL-based provisioning.
Today, users who want to use Memori with Postgres still need to manually create a database, copy the connection string, configure it, and then initialize Memori. That works, but it adds friction for quickstarts, examples, demos, and agent/developer-tool workflows where we want Memori to be ready with minimal setup.
This is related to the original database provisioning proposal in #463, which called out Neon Launchpad as the PostgreSQL-family equivalent to TiDB Zero.
The Solution
Add support for neon-launchpad as a database provisioning provider, following the same general pattern used for TiDB Zero.
The provider should create or retrieve a Neon Launchpad Postgres database, return a standard Postgres connection string, and allow Memori to initialize the existing schema through the normal PostgreSQL storage path.
Example usage could look something like:
memori provision --provider neon-launchpadAnd in Python, if supported by the existing provisioning API:
mem = Memori.provision(provider="neon-launchpad", build=True)The provider should return the same style of provisioning result used by the TiDB Zero implementation.
Important implementation details:
* Reuse the existing PostgreSQL storage driver path.
* Keep provisioning separate from storage drivers.
* Follow the same provider abstraction used by TiDB Zero.
* Redact credentials in logs and CLI output.
* Surface useful provider metadata such as `claim_url` and `expires_at` if Neon returns them.
* Avoid creating duplicate databases on repeated local runs if the existing provisioning cache pattern applies.
* Add tests/docs consistent with the TiDB Zero provisioning implementation.
### Alternatives Considered
Users can already create a Neon database manually and pass the connection string into Memori as a normal PostgreSQL BYODB target. That should continue to work and should remain the recommended path for users who want full control over their database.
This feature is specifically for reducing setup friction in quickstarts, demos, local development, and agentic workflows where Memori can provision a temporary or claimable Postgres database automatically.
### Affected Components
CLI, Vector Store / Memory
### Participation
- [ ] I am willing to submit a pull request for this feature.Source: MemoriLabs/Memori