@sohee I’ve looked at all these online databases, and virtually all of them do what Grist does, i.e. ignore foreign key constraints at the database level and implement it at the application level. BTW, Nocodb doesn’t do this, but I can never get nocodb to work, so I gave up on that project. Anyway, I presume they all do this b/c it makes the application UI faster and easier to implement some features that wouldn’t be possible with a foreign key constraint. Is it a bad design choice? Who knows. Personally, it makes me gasp in horror, as I was trained on basic db theory. But, as long as application is battle-tested (and Grist is), I guess it doesn’t matter. I haven’t yet had any issues with Grist regarding this. The main issue, of course, is as you realized: The database isn’t really portable. You can backup the SQLite file, but if you import it into some other program, other than Grist, it is useless b/c none of the relationships are actually set at the database level. My own idea now, since I like Grist so much, and it has made me so productive, is to consider setting up webhooks to back up each document in Grist into a regular postgres database, to maintain all relationships. That also will facilitate some ability to move in case the database gets too large at Grist (100K row limit). Still not sure exactly how it will work, though.