Ecosystem Integrations
AionDB should feel like a PostgreSQL-facing database before it asks users to learn AionDB-specific features. The integration strategy is therefore pgwire first, then AionDB extensions for graph and vector workflows.
Current Public Integrations
| Surface | Status | Validation path |
|---|---|---|
psql | primary smoke-test client | SELECT 1, DDL, DML, transactions |
| PostgreSQL drivers | feature-by-feature | simple query, prepared query, transaction errors |
| pgAdmin 4 | local compose profile | make dashboard-pgadmin |
| Embedded Rust | direct engine API | compile examples and application tests |
| SQL dump/restore | supported v0.1 safety path | aiondb dump, aiondb restore, aiondb doctor |
pgAdmin
Start AionDB, then run:
make dashboard-pgadminThe pgAdmin profile connects over the PostgreSQL wire path. Use it to verify that ordinary SQL tools can inspect schemas and run queries without a custom client.
Driver Checklist
For every driver or ORM, record:
- driver name and version;
- simple query support;
- prepared query support;
- transaction error behavior;
- type mappings used by the application;
- catalog introspection queries generated by the tool;
- reduced SQL file for each mismatch.
Native Extension Surfaces
AionDB-specific graph and vector features should remain visible, but they should not block basic PostgreSQL tooling. The dashboard and docs can provide snippets, graph previews, and capability metadata while generic SQL clients keep working through pgwire.
Claiming Support
Do not mark an ecosystem surface as supported because it connects once. Mark it supported only when the application path has a reproducible smoke test and a known limitations section.