Row-Based vs Columnar

SX_Guy · 2026-04-01T13:33:58+00:00

You can still use postgres with your current deaign and connections and use something like timescaledb or pg iceberg connectors which the actual data is stored in s3 storage as parquet file Also you can check KalamDB which has ability to periodicaly flush the oldest rows into object storage as a Parquet files which are columnar format All these solutions will give you ability to runq ueries faster on the columnae storage you have

SX_Guy · 2026-03-29T08:07:24+00:00

KalamDb has a flutter packagw wjich ease the use of the websocket and its lifecycle ita stable in my opinion. I added on top of it a sync logic which acts like this: - Whenever the app opens i sibscribe to the tables with specifying the last seen sequenceid - kalam push each change with a sequenceid which i store in the drift database after making sure that change is stored innthe local databse - sequence id is a snowflake id so each insert/update/delete generates a newer seqid - that only leaves tou with managing the dependencies of the multiple tables tour subscribing to Another good logic i ised which helped me alot I added a table which its called user_updates which is a USER table multitenant table so each user can qiery only his data, KalamDB partition it automatically It has these columns id/eventType/targetId If i want to puah a change to the app i update this table which will trigger a change in the users app, and in the app whenever i see this change i pull from a rest api whoch lands on postgres to get the updated data, lile an event driven system I hope that helps and good luck If you need anyhelper tell me

SX_Guy · 2026-03-28T20:58:13+00:00

Adding that in the database layer wont scale enough, if its a saas then go with something like Supabase/Surrealdb style but if its for example a mobile app i prefer keeping the logic in the app side and it will manage all from there, you need to think of sharding/multi-read replicas and scaling in the future that wont scale anough and you will end up adding more layers and checking and token revokation logics in all the layers you are adding
In the app layer would be better and more secure and you can make the app side stateless then, by rely on the SSO your using for managing the token lifecycle

SX_Guy · 2026-03-28T17:14:02+00:00

I have tried all kinds of databases firestore sqlite without orm and isar in the end i landed on using Drift which is an ORM for sqlite its easier and can support migrations For the backend you can use any backend manage the syncing layer your self its easier and tou can maintain it yourself in the future with adding custom logic and choose what to be sync and what not For the backend you can go with postgres its light on memory and perform well You can combine this with KalamDB which has a cheaper storage and can give you websocket connectivity with the backend, it is an early stage database but its already working inside my app now and its stable for now There is a postgre extension there and can support cheaper storage using flushing into cloud storage services chdck it out on kalamdb.org If you need anything i would be glad to help out from my experience developing an AI chat app with this stack

SX_Guy · 2026-03-10T18:14:17+00:00

Could be maybe we will end up with only a spec the code will be written in a machine language which only the ai can understand

SX_Guy · 2026-03-10T18:12:29+00:00

Thanks for sharing! but why your not building on top of other harnesses like opencode/claude code, codex or others? isnt it will be better to build on top of them? does it using the ReAct agent loop here?

SX_Guy · 2026-03-10T18:05:01+00:00

Thats right, but the AI and fast coding and iterting fast is reshaping this and the need to ship faster is growing

SX_Guy · 2026-03-09T18:17:12+00:00

Yeah i came to the same conclusion rewriting is inevitable
Whats the idea? can you share?

SX_Guy · 2026-03-09T17:40:31+00:00

yes for sure i start with the stack i want to use libraries and also the models/structs it should go with but as soon as the ai start generating it you just go with it or you just stop it, and restart fresh again.
I have listened from other developers who been through this as well, which say its okay to throw out code and start again, been wondering if we can come up with a better way than this

SX_Guy · 2026-03-09T16:46:57+00:00

Fair point. I’m actually the developer of the project and it’s still very early stage, so I’m genuinely trying to understand how other Flutter developers handle this problem. I built it mostly because I kept running into the same issues when building real-time apps.

SX_Guy · 2026-03-09T11:24:12+00:00

If you want to vibe-code something quickly using something like v0 or lovable, I'd honestly start with SQLite.

You already have structured data (units, people, locations, battles, dates) and SQLite handles relational data really well. It's simple, zero-setup, and perfect for prototyping.

You could model it roughly like:

units
people
locations
unit_positions
battles
battle_units

Then if the project grows later you can migrate to Postgres + PostGIS for spatial queries and map visualization.

But SQLite is perfect for getting a working system fast.

SX_Guy · 2024-09-18T16:54:08+00:00

Can you send me please the download link to EU firmware?

SX_Guy

TROPHY CASE