thin-backend VS differential-dataflow

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.

Some recent solutions to this problem include Differential Dataflow and Materialize. It would be neat if postgres adopted something similar for live-updating materialized views.

https://github.com/timelydataflow/differential-dataflow

https://materialize.com/

I'm looking for this but can't find it, how does this project compare to differential dataflow?

As a sibling commenter mentioned, it's built on timely dataflow (which is lower-level), but that already has differential dataflow[0] built on top of it by the same authors.

How do they differ?

[0]: https://github.com/TimelyDataflow/differential-dataflow

hi! sujay from convex here. I remember reading about your "reverse query engine" when we were getting started last year and really liking that framing of the broadcast problem here.

as james mentions, we entirely re-run the javascript function whenever we detect any of its inputs change. incrementality at this layer would be very difficult, since we're dealing with a general purpose programming language. also, since we fully sandbox and determinize these javascript "queries," the majority of the cost is in accessing the database.

eventually, I'd like to explore "reverse query execution" on the boundary between javascript and the underlying data using an approach like differential dataflow [1]. the materialize folks [2] have made a lot of progress applying it for OLAP and readyset [3] is using similar techniques for OLTP.

[1] https://github.com/TimelyDataflow/differential-dataflow

[2] https://materialize.com/

[3] https://readyset.io/

differential dataflow which is used to power materialize db

It's partially inspired by Linq, so the similarity you see is expected.

It's not really arbitrary structures so much, though you're mostly free in what record type you use in a relation (structs and tagged enums are typical, though).

The incremental part is that you can feed it changes to the input (additions/retractions of facts) and get changes to the outputs back with low latency (you can alternatively just use it to keep an index up-to-date, where you can quickly look up based on a key (like a materialized view in SQL)).

This [0] section in the readme of the underlying incremental dataflow framework may help get the concept across, but feel free to follow up if you're still not seeing the incrementality.

[0]: https://github.com/TimelyDataflow/differential-dataflow#an-e...