doltgresql
goose
doltgresql | goose | |
---|---|---|
5 | 29 | |
948 | 5,842 | |
12.0% | 6.9% | |
9.7 | 8.9 | |
5 days ago | 9 days ago | |
Go | Go | |
Apache License 2.0 | GNU General Public License v3.0 or later |
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
goose
-
Recent improvements to the pressly/goose migration tool
In v3.16.0 we added a new Provider feature that unlocks the ability to implement a lot of highly requested features. More details in the blog post:
- How are y'all that are using raw sql doing DB Migrations?
- Why elixir over Golang
- Is there a similar tool or alternative in Go like strong_migrations?
-
How do you handle migrations ?
Next try https://github.com/pressly/goose We have this setup to be run by the CI-CD pipeline to be run before the application is started. BTW, this utility is compatible with https://sqlc.dev , so they work good together.
-
Does this project structure make sense?
For database migration I recommend https://github.com/pressly/goose As it works with sqlc and is a powerful tool for complex migrations. This is something a lot of ORMs are really weak with. I was on a large project with Gorm as the ORM and what a nightmare when we pushed to production!
- Are there any decent ORMs in Golang?
- Don't Mock the Database
-
Writing tests for APIs
goose https://github.com/pressly/goose - data migration and seed data creation
-
A beginner's guide to creating a web-app in Go using Ent
I'm using .sql migration files with tooling similar to https://github.com/pressly/goose . Is there a way to manage my schema with my pre-existing tooling and my queries/CRUD operations with Ent/Atlas?
What are some alternatives?
pREST - PostgreSQL ➕ REST, low-code, simplify and accelerate development, ⚡ instant, realtime, high-performance on any Postgres application, existing or new
migrate - Database migrations. CLI and Golang library.
usql - Universal command-line interface for SQL databases
dbmate - :rocket: A lightweight, framework-agnostic database migration tool.
SQLBoiler - Generate a Go ORM tailored to your database schema.
go-migrate - Abstract task migration tool written in Go for Golang services. Database and non database migration management brought to the CLI. [Moved to: https://github.com/g14a/metana]
dolt - Dolt – Git for Data
liquibase - Main Liquibase Source
FerretDB - A truly Open Source MongoDB alternative
alembic - A database migrations tool for SQLAlchemy.
bytebase - The GitHub/GitLab for database DevOps. World's most advanced database DevOps and CI/CD for Developer, DBA and Platform Engineering teams.
pig - Simple pgx wrapper to execute and scan query results