There's this application I've been writing and re-writing my whole career: I call it "some users design forms, other users fill out forms." It is hard to design the db as anything other than EAV. (You can push more or less of it into JSON columns, but there are tradeoffs.)
I have often wondered about pushing the customizability down a level though, like what the author does here, where each form creates a separate database table. It's too crazy for me, but it's tempting. And I have actually done it before where users' forms automatically generate individual tables in a separate flattened reporting database. It works really well for giving enterprise customers SQL access to an OLAP view of their data, even if I wouldn't use it for my source-of-truth OLTP structure. (Some day I'm going to write a blog post about that.)
Even just for derived reporting tables, you quickly discover all kinds of limits in your database: reserved words, max columns per table, max columns per query, number of foreign keys pointing at a central table, etc. I haven't hit anything fatal though (with Postgres).
Anyway, I'm excited to see that someone actually pulled this off, complete with Django models and migrations, even if it's just for fun.
Postgres JSONB columns could give you a lot of that without actually creating seperate tables - for instance indexes over embedded keys.
This. The best of both worlds + you get querying inside of the JSON.
I once wrote something very similar to this as a literal proof-of-concept hack for a form-oriented problem. It's fun to get it to the point where it works for the simplified test cases such projects always start out with.
But I never used it beyond that proof-of-concept; I still reach for EAV and/or JSON columns when I need to do this sort of thing for production software.
Something like https://form.io/ ?
JSON Schema Form might be of interest to you.