tldr; you can do jobs, queues, real time change feeds, time series, object store, document store, full text search with PostgreSQL. How to, pros/cons, rough performance and complexity levels are all discussed. Many sources and relevant documentation is linked to.
Your database is first. But can PostgreSQL be second?
Web/app projects these days often have many distributed parts. It's not uncommon for groups to use the right tool for the job. The right tools are often something like the choice below. Redis for queuing, and caching.Elastic Search for searching, and log stash.Influxdb or RRD for timeseries.S3 for an object store.PostgreSQL for relational data with constraints, and validation via schemas.Celery for job queues.Kafka for a buffer of queues or stream processing.Exception logging with PostgreSQL (perhaps using Sentry)KDB for low latency analytics on your column oriented data.Mongo/ZODB for storing documents JSON (or mangodb for /dev/null replacement) SQLite for embedded. Ne…
to me... it's already usable. That is pygame (same one that runs on
cpython), works on pypy through its C extension API. pypy has good
support for the CPython API (through a recompile) now. PyPy is the python language with a fast JIT, so your code can approach C speeds. And in some cases it can be faster than C.
an issue with events stopping keyboard/mouse/etc from working. Lots of
details in this issue describing the changes needed, so I hope other
extensions encountering this will find it useful. https://github.com/pygame/pygame/issues/419
But now that's fixed, every pygame app I tried on it has worked.
Why is this exciting?
This is exciting to me because: pure python code being fast on pypy(after warmup), also mixed with the fast bits in C/asm.cpyext is getting faster in pypy. There is already work and discussion toward…
TLDR; less performance spikes, faster average performance, PyPy is a good Python for games and multimedia apps on desktop systems, running GC in a thread is a good idea for GIL releasing apps.
In March 2018 at the PyPy winter sprint I spent some days working on improving pygame support on PyPy. Part of this was investigating pypy frame drop. In there I found PyPy had both lower average performance in this pygame-using-CPython-API benchmark, and had spikes which caused frame drops. Remember that in latency sensitive applications performance spikes are not allowed. Note that not very much of this code is pure python (where PyPy is fastest), so it's almost a worst case benchmark for PyPy performance.
Thanks to Antonio, the PyPy team and their supporters — things have much improved since then. One improvement in particular is that PyPy now allows more control of when the Garbage Collection does its work. Read more about it in the blog post "PyPy for low latency systems".