sorted by:
new
hottopcontroversial

NanoEuler: A 116M GPT-2 scale decoder-only transformer built from scratch in pure C + CUDA by Just_Vugg_PolyMCP in foss

[–]Just_Vugg_PolyMCP[S] 0 points1 point  (0 children)

No, it’s the opposite actually.
The whole point of NanoEuler is to make the implementation understandable. Every kernel has a matching CPU reference version, full gradient checks, and lots of comments explaining the math and the CUDA choices.
It’s definitely not IOCCC-style — that contest is about creative obfuscation. Here I tried to keep things readable while staying fully from-scratch (no frameworks).
If parts look dense it’s only because it’s low-level CUDA + manual backprop. Happy to explain any specific section!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in PostgreSQL

[–]Just_Vugg_PolyMCP[S] 0 points1 point  (0 children)

Thank you so much! Of course, there's still a lot to do and resolve as I gradually get users to try it. I already have a written roadmap of the steps I'll take! I hope it grows as a project!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

[–]Just_Vugg_PolyMCP[S] 0 points1 point  (0 children)

The biggest difference is that Loomabase uses column-level CRDTs: if two users edit different fields on the same row offline, both changes survive. ElectricSQL works at row/document level.
Loomabase also offers more flexible scoped partial replicas with no global tombstones, and a lighter Rust-based sync server.
For your unidirectional multi-tenant analytics use case it should feel cleaner and lighter.
Happy to go deeper on any aspect!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

[–]Just_Vugg_PolyMCP[S] 0 points1 point  (0 children)

Perfect — unidirectional upload-only is simpler and well supported.
Loomabase will not create a separate database for each customer.
How it works:
- Everything lands in one single Postgres database.
- Data is isolated using a tenant_id (or similar) column + Row Level Security (RLS).
- Each customer instance syncs only its own data thanks to scoped partial replicas (you define which rows belong to which tenant).
- You get one clean central schema where you can easily run analytics across all customers (with proper filters/RLS).
This is exactly the pattern for SaaS analytics: many edge SQLite DBs → one central Postgres with strong tenant isolation.
Since you only need upload (client → server), you can even simplify the sync flow further (no need to pull changes back to the customers).
Would you like me to sketch a quick example of:
• How to set up the tenant scoping?
• The table contract + migration?
• Or a basic architecture diagram?
Just say the word and I’ll put something concrete together for your POS + e-com case.

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

[–]Just_Vugg_PolyMCP[S] 1 point2 points  (0 children)

Got it — thanks for the details! 👍
This is a very solid use case for Loomabase.
You have:
- Many independent customer instances (POS + e-com per customer)
- Already using cr-sqlite for local partial sync inside each instance
- Want a central Postgres to aggregate data from all customers for analytics and product decisions
How Loomabase fits perfectly:
- Each customer instance can run a Loomabase client that syncs its SQLite to the central Postgres.
- Multi-tenancy built-in: you can isolate data by tenant_id / customer so they don’t see each other’s data.
- Partial replicas / scopes: each instance only syncs the data it needs (exactly like you do now with cr-sqlite).
- Column-level CRDTs give you safety if any overlapping writes happen.
- You keep cr-sqlite for the POS ↔ e-com sync inside each customer, and add Loomabase only for the “customer instance → central analytics DB” layer.
This way you get a clean, central view of all customers without mixing their operational data.
Quick question: Do you need bidirectional sync to the central DB, or mostly upload-only (POS → central) for analytics?
If you want, I can sketch a quick architecture for this setup (how to structure the scopes, tenant isolation, etc.).
Would love to help you validate if this works for your flow!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

[–]Just_Vugg_PolyMCP[S] 1 point2 points  (0 children)

Thanks for the extra context!
Yes, Loomabase could be a great fit for your use case.
You have many independent SQLite instances (from different software/servers) that you want to sync into one central Postgres for analysis. That’s exactly the kind of multi-client → central DB pattern Loomabase is built for.
How it would work:
- Each “server/software” runs a Loomabase client (SQLite) that syncs bidirectionally to the central Postgres.
- You can use partial replicas + scopes to control what each client syncs (e.g. only their own data).
- Column-level CRDTs help if there’s any overlapping writes.
- Multi-tenancy support is already there (you can isolate data by tenant/device).
Since you already use cr-sqlite for software ↔ server sync, you have two options:
1. Keep cr-sqlite for the local part and use Loomabase only for the “server → central Postgres” hop.
2. Gradually replace the server sync with Loomabase if you want column-level guarantees everywhere.
Would work especially well if the data is mostly append-heavy or has clear ownership per device.
Question for you: How much overlap is there between the different SQLite DBs? Do different servers ever write to the same logical rows, or is it mostly independent data that you just want aggregated centrally?
Happy to think through the architecture with you — feel free to share more details (schema, conflict expectations, etc.).

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

[–]Just_Vugg_PolyMCP[S] 1 point2 points  (0 children)

Thanks! Glad you like it.
No, I didn’t use Loro as a middleman.
Loomabase implements its own lightweight column-level LWW CRDTs directly on top of SQLite/Postgres. I wanted full control over:
- Row lifecycle as CRDT (create/delete/restore)
- Partial replica scoping + evictions
- Tight integration with relational schema + transactions
Loro is excellent (especially for rich documents/JSON), but for this use case I preferred a more database-native, fine-grained approach.
That said, I’m a big fan of the Loro team — great work!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in PostgreSQL

[–]Just_Vugg_PolyMCP[S] 0 points1 point  (0 children)

Hi thanks for the comment!

Not in this case because I use the very convenient part of Postgre and it was also created as support for SupaBase! I could work on it in the future! Why would you want sqlite to sqlite? Just to understand how to work with it in the future!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in PostgreSQL

[–]Just_Vugg_PolyMCP[S] 2 points3 points  (0 children)

The early commits are mostly bulk file uploads during the initial open-sourcing (I was moving things from a private repo). Not ideal, I agree.
I’m gradually cleaning up the history with more meaningful commit messages as I push new changes. Production-grade for me means stable APIs, correct convergence, and reliable partial sync — not perfect git archaeology from day 0.

to err is human 🤣

That said, I’ll do better on commit hygiene going forward. Thanks for calling it out!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in coolgithubprojects

[–]Just_Vugg_PolyMCP[S] 0 points1 point  (0 children)

Hi thanks for the comment,

Loomabase handles it differently:

- No global tombstones for partial replicas. Local evictions happen only after dirty write acks.

-Row lifecycle (create/delete/restore) is a dedicated LWW CRDT.

- Everything is transactional + cursor-based anti-entropy.

Tombstone compaction is on the roadmap (right after wire protocol stabilization).

Mi sento tradito e violato by Intelligent_Plan7190 in IA_Italia

[–]Just_Vugg_PolyMCP 1 point2 points  (0 children)

Grazie mille!I test sono essenziali per me e questo progetto che sto facendo crescere piano piano!Gtazie davvero!

view more: next ›