postgresql pg-datahike 0.1 — PostgreSQL wire protocol + SQL translator for Datahike
Datahike now speaks Postgres. Point any PG client (pgjdbc, psql, psycopg2, Hibernate, SQLAlchemy, Odoo, Flyway/Alembic) at a Datahike connection and it just works. Bidirectional at the datom layer — CREATE TABLE over pgwire transacts normal Datahike schemas + datoms; existing Datahike databases become SQL-queryable with zero setup; (d/q …) and SELECT * FROM person see the same rows.
Four capabilities on top of plain SQL:
• Multi-DB routing — jdbc: picks the conn from a {name → conn} registry
• Schema hints — : meta-attrs rename columns, hide attrs, mark FK targets on existing Datahike schemas
• Temporal SET — SET exposes d/as-of / d/since / d/history as session vars
• Git-like branching — SELECT datahike.create_branch('feat', 'main') is O(1), no provisioning; SET datahike.branch = 'feat'; SET datahike.commit_id = '<uuid>' queries an exact historical commit (no other PG-compatible database offers that)
Verified end-to-end: pgjdbc ResultSetTest 80/80, Hibernate DatahikeHibernateTest 13/13, SQLAlchemy 7-phase 16/16, Odoo 19 module boot + TestORM.
clojure
{:deps {org.replikativ/datahike {:mvn/version "LATEST"}
org.replikativ/pg-datahike {:mvn/version "LATEST"}}}
EPL 2.0 · <https://github.com/replikativ/pg-datahike>I would love to get feedback on this, in particular what people actually need. It provides Datoimic-style horizontal scaling to SQL databases. Besides the obvious benefits this also helps to stress test Datahike features more with real applications, since it translates SQL into Datalog internally (maybe this is also of interest itself) and makes use of our new query planner. This helped me to fix a bug in its or-join logic and we also now have first-class plan support for get-else clauses which support nil values in columns (used in SQL by default and mapped onto by the pg layer).
I'm not using Datahike on any projects that need this right now, but one use-case I can imagine is to connect an existing analytics solution (e.g. Metabase) that supports PostgreSQL natively.
Yeah metabase would be a huge unlock
Working on it. What specifically would it unlock? @alekcz360
Had the same thought but with https://mathesar.org which installs its own pg extensions, I think
Sneak peek for an announcement blog post https://datahike.io/notes/datahike-speaks-postgres/. Feedback welcome!
Quite a few improvements and fixes have landed, including a pre-packaged jar that acts like a Postgres server.
I have some self-deployed services that use postgresql. If I wanted to switch to datahike, should I dump the postgresql databases and import them into datahike via this postgresql adapter? Would that result in a “good” datahike schema?
Small nit, I was thrown by the name. When I see pg-* I assume that's something I would add to postgresql. A name like datahike-pg probably would have signaled to me more clearly that this is a datahike addon. Again, small nit
Incorporated the first round of feedback and put out a new release. Metabase queries seem to work reasonably well now including its test suite. This required adding proper array support and covering quite a bit more of Postgres. I have not run the app on top myself yet though. Mathesar should run with an initial mapping of its function import says Claude. Many of the admin functions needed for pgadmin and similar tools including catalog functions are also added. Further feedback welcome. Please open issues if you run into any.
It means that non developers could query datahike. They could ask Claude to give them queries to do their analysis, leaving me in peace
Yes, I think there are quite a few angles on this that are fairly useful, even without complete or perfect Postgres coverage. Claude does know Datalog fairly well though, my idea so far was more to cohost "legacy" apps that are not Datahike ontop of the same stack and being able to nicely query them from Clojure through Datalog and also benefit from all the full persistent memory semantics and ability to scale out. A business possibility would be to provide a more scalable Postgres as a service (with full read scaling), but I am currently not planning to provide this.
Yes, I added support for dumping and importing https://github.com/replikativ/pg-datahike#migration--pg_dump-interop. Happy to get feedback if you try @tvaughan. I opted for pg-datahike, because it does offer datahike through the lens of postgres, we already have daatahike-lmdb and other (now deprecated) projects like datahike-jdbc which provided datahike backends. Maybe you are right and I will rename it down the line, but I think the name is not unreasonable.
Published the updated post, will think about where to share it tomorrow.
I love it!!! Makes it easier for non datahike environemnts (clojure .net; other languages) to access datahike data without having to export data or write apis to access it. thanks a lot!!