doltgresql VS FerretDB

PostgreSQL support here

https://github.com/dolthub/doltgresql

Background and architecture discussion here

https://dolthub.com/blog/2023-11-01-announcing-doltgresql/

We're writing a postgres-compatible database that doesn't use any postgres code:

https://github.com/dolthub/doltgresql/

We're doing this because our main product (Dolt) is MySQL-compatible, but a lot of people prefer postgres. Like, they really strongly prefer postgres. When figuring out how to support them, we basically had three options:

1) Foreign data wrapper. This doesn't work well because you can't use non-native stored procedure calls, which are used heavily throughout our product (e.g. CALL DOLT_COMMIT('-m', 'changes'), CALL DOLT_BRANCH('newBranch')). We would have had to invent a new UX surface area for the product just to support Postgres.

2) Fork postgres, write our own storage layer and parser extensions, etc. Definitely doable, but it would mean porting our existing Go codebase to C, and not being able to share code with Dolt as development continues. Or else rewriting Dolt in C, throwing out the last 5 years of work. Or doing something very complicated and difficult to use a golang library from C code.

3) Emulation. Keep Dolt's Go codebase and query engine and build a Postgres layer on top of it to support the syntax, wire protocol, types, functions, etc.

Ultimately we went with the emulation approach as the least bad option, but it's an uphill climb to get to enough postgres support to be worth using. Our main effort right now is getting all of postgres's types working.

Very cool. I wonder when it makes sense to engineer things at this level vs using something like Azure AI search. [0]

Love to see version control on all the things! Wonder if the version control features would be more robust if implemented in Doltgres.

[0] https://azure.microsoft.com/en-us/products/ai-services/ai-se...

[1] https://github.com/dolthub/doltgresql

if you have postgres, just use https://github.com/FerretDB/FerretDB

FerretDB is an open source document database that adds MongoDB compatibility to other database backends, such as Postgres and SQLite. By using FerretDB, developers can access familiar MongoDB features and tools using the same syntax and commands for many of their use cases.

There is FerretDB. But they are not fully compatible to Mongo yet.

https://www.ferretdb.io/

Feature parity progress with apps:

https://github.com/FerretDB/FerretDB/issues/5

I presume, that after there is feature parity, then someone could run some benchmarks.

Yep that's serious issue and it's similar to our case. Our main product can work just fine even without SSE 4.2 but MongoDB requires it and then indirectly leads to AVX1 support as we use MongoDB as storage. We did PoC with FerretDB last month and I think it may be good option for Gerylog: https://www.ferretdb.io

Shout out to FerretDB, which is an in progress open source re-implementation of MongoDB atop PostgreSQL.

https://github.com/FerretDB/FerretDB