doltgresql
vitess
doltgresql | vitess | |
---|---|---|
5 | 60 | |
948 | 17,912 | |
12.0% | 1.1% | |
9.7 | 9.9 | |
about 17 hours ago | about 21 hours ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
doltgresql
-
A MySQL compatible database engine written in pure Go
PostgreSQL support here
https://github.com/dolthub/doltgresql
Background and architecture discussion here
https://dolthub.com/blog/2023-11-01-announcing-doltgresql/
-
Postgres is eating the database world
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.
-
Show HN: Dera – A platform to manage chunks and embeddings for building RAG apps
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
- Show HN: DoltgreSQL – Version-Controlled Database, Like Git and PostgreSQL
vitess
-
A MySQL compatible database engine written in pure Go
With Vitess likely merging a lot of its binaries into a single unified binary: https://github.com/vitessio/vitess/issues/7471#issuecomment-...
... it would be a wild future if Vitess replaced the underlying MySQL engine with this as long as the performance is good enough.
-
The challenges of supporting foreign key constraints
Thank you for the compliment!
We recently started adding support for CTEs in Vitess! You can check out https://github.com/vitessio/vitess/pull/14321 if you want to see some technical details of the implementation.
For now, we have added preliminary support by converting them to derived tables internally, but we believe that we need to make CTEs first-class citizens themselves of query planning. Once we make that change, we can look towards supporting recursive CTEs.
This however will take some time, but then, all good things do!
-
Vitess 18
Why would it be a Google project? https://github.com/vitessio/vitess
-
PlanetScale Scaler Pro
This is great news. I strolled around https://github.com/vitessio/vitess/issues/12967.
Are there any public discussions of more trade-offs vitess has to make to enable fks?
-
What is the best database technology to use to create a new chat app today?
MySQL + Vitess I noticed Slack gets by using MySQL because they're using Vites. From Slack's post (https://slack.engineering/scaling-datastores-at-slack-with-vitess/) it seems like they choose Vites because it facilitated a smooth transition because it's built on top of MySQL.
- Vitess – Scalable. Reliable. MySQL-Compatible. Cloud-Native. Database
-
How can I avoid duplicate API calls in a serverless infra?
This sounds very similar to the connection pooling done by vitess https://vitess.io/.
-
Scaling Databases at Activision [pdf]
https://github.com/vitessio/vitess/issues/12967
-
Want to avoid MySQL but find PlanetScale really appealing
A lot of this is possible thanks to the magic of Vitess.
-
Vitess 16
"Vitess is a database clustering system for horizontal scaling of MySQL."
https://github.com/vitessio/vitess
What are some alternatives?
pREST - PostgreSQL ➕ REST, low-code, simplify and accelerate development, ⚡ instant, realtime, high-performance on any Postgres application, existing or new
tidb - TiDB is an open-source, cloud-native, distributed, MySQL-Compatible database for elastic scale and real-time analytics. Try AI-powered Chat2Query free at : https://tidbcloud.com/free-trial
usql - Universal command-line interface for SQL databases
supabase - The open source Firebase alternative.
SQLBoiler - Generate a Go ORM tailored to your database schema.
cockroach - CockroachDB - the open source, cloud-native distributed SQL database.
dolt - Dolt – Git for Data
citus - Distributed PostgreSQL as an extension
goose - A database migration tool. Supports SQL migrations and Go functions.
go-mysql-elasticsearch - Sync MySQL data into elasticsearch
FerretDB - A truly Open Source MongoDB alternative
kingshard - A high-performance MySQL proxy