thin-backend VS dolt

A tool like https://thin.dev/ might be good for you. You can port and serve functionality a little bit at a time into thin and use their managed postgres db and the schema editor to handle the new fields in the backend.

Check out thin.dev https://thin.dev/ It uses SQL DDL statements literally as the building blocks for everything.

Postgres database has been gaining more popularity because of its advanced database and scalability. Created by digitally induced, Thin Backend is simplifying Postgres by giving users a backend server that has an API that connects with Postgres DB. You can integrate Thin Backend with:

React for UI TypeScript for Type Safety thin.dev for Data + State management

Check out https://thin.dev/ :) It's similar, supports self-hosting and uses postgres. Quick demo video here: https://www.youtube.com/watch?v=-jj19fpkd2c&t=3s

(I'm founder of Thin)

Real-time by default for everything is really a fun way to write web apps. A little bit inspired by Meteor we've build Thin Backend, which provides a real-time API for querying data and writing to a postgres database. If you're interested, check it out at https://thin.dev/ or check the demo video https://www.youtube.com/watch?v=-jj19fpkd2c

If you're curious, give it a try at thin.dev.

Before Dolt appeared on my radar, I thought this problem was non-trivial, and very difficult to implement: Whenever a fork occurs, or blocks arrive at your node that conflict with your current chain, you have to validate these new blocks against a snapshot of your data at a specific point in time. This point in time is determined by the parent block hash of the incoming blocks. This requirement for "time-travel" has always deterred me from attempting my own blockchain implementation. I know that there are blockchains out there that have (maybe?) solved this, but I'm not as good as a programmer as those guys. If you're anything like me, maybe you can relate.

I hadn’t seen that before and I can’t speak to the quality of the project, but I wanted to call out the first section in the readme [0] for being perfectly clear and succinct:

> Git versions files. Dolt versions tables. It's like Git and MySQL had a baby.

> We also built DoltHub, a place to share Dolt databases. We host public data for free. If you want to host your own version of DoltHub, we have DoltLab. If you want us to run a Dolt server for you, we have Hosted Dolt. If you are looking for a Postgres version of Dolt, we built DoltgreSQL. Warning, it's early Alpha. Dolt is production-ready.

[0] https://github.com/dolthub/dolt?tab=readme-ov-file#dolt-is-g...

We built a MySQL-compatible one and are building a Postgres-compatible one :-) Free and open source.

https://github.com/dolthub/dolt

We use the reset functionality to speed up our tests.

https://www.dolthub.com/blog/2022-06-10-enginetest-perf/

Hi, this is my project :)

For us this package is most important as the query engine that powers Dolt:

https://github.com/dolthub/dolt

We aren't the original authors but have contributed the vast majority of its code at this point. Here's the origin story if you're interested:

https://www.dolthub.com/blog/2020-05-04-adopting-go-mysql-se...

It's a pretty good default stance, yeah.

We have been trying to convince people to use our new database [1] for several years and it's an uphill battle, because Postgres really is the best choice for most people. They really have to need our unique feature (version control) to even consider it over Postgres, and I don't blame them.

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

We implemented a query optimizer with a flexible intermediate representation in pure Go:

https://github.com/dolthub/go-mysql-server

Getting the IR correct so that it's both easy to use and flexible enough to be useful is a really interesting design challenge. Our primary abstraction in the query plan is called a Node, and is way more general than the IR type described in the article from OP. This has probably hurt us: we only recently separated the responsibility to fetch rows into its own part of the runtime, out of the IR -- originally row fetching was coupled to the Node type directly.

This is also the query engine that Dolt uses:

https://github.com/dolthub/dolt

But it has a plug-in architecture, so you can use the engine on any data source that implements a handful of Go interface.