Have you tried fastapi? It uses starlette as its base. Such a lovely experience working with it.

I haven't tried it but I did look it over when I was investigating Starlette. May try it out in the future, it seems powerful, and I read about a few projects using it. I ended up just rolling with Starlette because I liked how minimal, yet flexible it was (why FastApi etc built on it).

We are also using starlette and works quite well.. in combination with asyncpg..

Do you use any db connection wrappers around asyncpg? Like encode/databases or gino? Also important to note that SQLAlchemy 1.4 alpha with asyncpg support is realease and can be tried out(both SQLAlchemy core&orm modes support it). I myself evaluated all options of async postgress connection wrappers in fastapi project but reverted to... just using sync psycopg2 through sqla core. No very specific gains of async db connection for my use cases and sqlalchemy creator's comments on immaturity of async postgres drivers made my stick to what's battletested.

On one project we use Databases, with a custom opensourced "adapter" for sqlalchemy models: https://github.com/vinissimus/asyncom

Our cms, is based on Guillotina (https://github.com/plone/guillotina) that uses a Datastore more or less equivalent to the Zodb, and plone, but internally uses postgresql and asyncpg. We are active contributors on it, and since latest version it works around asgi (uvicorn). We also have some plans to make it a bit more psqlidiomatic (get rid of pickles, ....)

On other internal services, we use the raw asyncpg.pool, mostly because part of our bussiness logic it's inside prostgresql, and this doesn't feet super well with an ORM. Think on a 15 year old sql schema, that had evolved through different hands, and right now it's multitenant xD

Latest opensourced thing, it's a work queue based on plgsql, with asyncpg bindings. (https://github.com/vinissimus/jobs/).

So, we can say, we use asynpg in all possible forms.

We use https://github.com/samuelcolvin/buildpg, which is built by the same dude that built pydantic, which is also used in FastAPI.

It's neat, it's a query builder, not an ORM or any nonsense, and it makes queries a lot more manageable (bringing SQL logic into python primitives).

Nice one, but.. I prefer sqls that you can debug without rendering.. (it's not so manageable when you deal with ctes, window functions, joins different schemas, custom functions...

very nice! cool animations on tmpo.io! Right now I'm running things behind aws lambda & using dynamodb etc, have looked into using aioboto3 but haven't got there yet...

Some reasons I see for sticking with Django is that it is big and well known. So easier to hire devs that know it, plenty of knowledge on Stack Overflow and elsewhere. Plus a large ecosystem of packages. (We use Tornado at my current workplace, and we would be far better off with something like Django).

Definitely, agree, Django is a great framework and I've used it over the past 5+ years at many companies large and small. When I set off to build my own project I wanted to keep my code as lean as possible and that's one thing I like about Starlette. It gives you the basic blocks and lets you decide how to use it.