_ben_

I’m building Zindex [1], which is aimed at this exact “visual representation of executable workflows” layer.

What I'm solving for is AI-generated diagrams are usually one-shot: Mermaid/SVG/PNG gets emitted, but there’s no durable diagram state to update, validate, diff, or reuse.

Zindex makes the diagram itself structured state. Agents use a Diagram Scene Protocol (DSP) to patch nodes, edges, groups, relationships, constraints, and revisions; Zindex handles validation, layout, rendering, versioning, and storage.

So for Temporal/DBOS/Restate/Cloudflare Workflows, I’d imagine Zindex sitting beside the durable execution engine: the engine remains the source of truth for execution, while Zindex maintains the persistent, inspectable visual model derived from code or execution history.

[1] https://zindex.ai/

Zindex is a stateful diagram runtime for agents. Agents create diagrams by sending structured operations through the Diagram Scene Protocol (DSP) - the platform validates, normalizes, and renders durable scene state rather than one-shot output.

Thanks for the question. You’re right that S3 itself is simple and reliable, and yes, most engineers *can* write HTTP retries and multipart uploads. EdgeMQ isn’t trying to replace S3’s API, it’s what you need around S3 when you have lots of producers on the public internet.

It gives you:

* edge HTTPS endpoints (auto-scale, multi-region HA) * a WAL so accepted events aren’t lost * segmentation + compression * explicit commit markers for consumers * backpressure instead of silent data loss * and a standardized way every team lands data in S3

You could build that yourself on top of S3; many companies do. EdgeMQ exists for folks who wants that behavior but dont want to operate a custom HTTP to S3 ingest service forever.

Its also worth noting that its in the early stages and the next features to be developed are transformations whereby you can input format a (say, JSON) and deliver in s3 as format b (e.g. csv, parquet etc).

Thanks for the questions. At a very high level, the AI uses statistical models that learn in real-time and estimate how frequently the data on the database is changing. The TTL's get set accordingly and are set per SQL query. The model looks at many inputs such as the payload sizes being returned from the database as well as arrival rates.

If PolyScale can see mutation queries (inserts, updates, deletes) it will automatically invalidate, just the effected data from the cache, globally.

If you make changes directly to the database out of band to PolyScale, you have a few options depending on the use case. Firstly, the AI, statistical based models will invalidate. Secondly, you can purge - for example after a scheduled import etc. Thirdly, you can plug in CDC streams to power the invalidations.

Feel free to ping me if you would like to dig in deeper (ben at) and this document provides more detail on the caching protocol: https://docs.polyscale.ai/how-does-it-work#caching-protocol

This blog also goes in to detail on how invalidation works: https://www.polyscale.ai/blog/approaching-cache-invalidation...

At PolyScale [1] we tackle many of the same challenges. Some of this article feels a little dated to me but the data distribution, connectivity and scaling challenges are valid.

We use caching to store data and run SQL compute at the edge. It is wire protocol compatible with various databases (Postgres, MySQL, MS SQL, MariaDB) and it dramatically reduces query execution times and lower latency. It also has a JS driver for SQL over HTTP, as well as connection pooling for both TCP and HTTP.

https://www.polyscale.ai/

PolyScale [1] focuses on many of these issues. It provides a globally distributed database cache at the edge. Writes pass through to the database and reads are cached locally to the app tier. The Smart Invalidation feature inspects updates/deletes/inserts and invalidates just the changed data from the cache, globally.

1. https://www.polyscale.ai/

Yes, in the early versions of the automated invalidation, the logic cleared all cached data based on tables. That is no longer the case. The invalidations only remove the affected data from the cache, globally. You can read more here: https://docs.polyscale.ai/how-does-it-work#smart-invalidatio...

For database caching outside of PlanetScale, PolyScale.ai [1] provides a serverless database edge cache that is compatible with Postgres, MySQL, MariaDB and MS SQL Server. Requires zero configuration or sizing etc.

1.https://www.polyscale.ai/

Does CF workers support TCP yet?

PolyScale founder here. Assuming you are referring to PolyScale (rather than ClickHouse), the product is aimed at devs who dont want to build data distribution and caching. You can connect your database and then have global low-latency reads, without writing code. Useful for multi-region deployments, serverless/microservices/FaaS as well as simply scaling your origin db.

ClickHouse is used for computing Observability metrics within the UI. The automated caching algorithms do not use ClickHouse in any way. You can read more about the automation here: https://docs.polyscale.ai/how-does-it-work#caching-protocol or try the live demo here: https://playground.polyscale.ai/

Disclaimer: I am the founder of PolyScale [1].

We see both use cases: single large database vs multiple small, decoupled. I agree with the sentiment that a large database offer simplicity, until access patterns change.

We focus on distributing database data to the edge using caching. Typically this eliminates read-replicas and a lot of the headache that goes with app logic rewrites or scaling "One Big Database".

[1] https://www.polyscale.ai/

PolyScale [1] is a serverless plug-and-play database edge cache. Our goal is for devs to be able to scale reads globally in a few minutes. It’s wire compatible with Postgres, MySQL, MS SQL Server (more coming including no-sql).

It has a global edge network, so no infrastructure to deploy and AI managed cache and auto invalidation, so no cache configuration needed.

[1] https://www.polyscale.ai/

PolyScale | Remote (GMT -8 to GMT +3) | Full-time | https://www.polyscale.ai/

Founding team hires.

PolyScale is changing how databases are distributed and scaled. Our mission is to enable edge-first data by simplifying global caching for developers. We provide a smart database edge cache that plugs into your existing database and intelligently caches data globally. No code and no servers to deploy.

We're a small team tackling hard problems and growing fast. If you are passionate about developer experiences, data performance and are a curious problem solver, join us! We are currently hiring for:

* Software Engineer, Full Stack - React & TypeScript - https://www.polyscale.ai/careers/software-engineer-full-stac...

* Software Engineer, C++ Backend Proxy - https://www.polyscale.ai/careers/software-engineer-backend

* Product Marketing - spec coming soon - contact us for more details.

PolyScale | Remote (GMT -8 to GMT +3) | Full-time | https://www.polyscale.ai/

Founding team hires.

PolyScale is changing how databases are distributed and scaled. Our mission is to enable edge-first data by simplifying global caching for developers. We provide a smart database edge cache that plugs into your existing database and intelligently caches data globally. No code and no servers to deploy.

We're a small team tackling hard problems and growing fast. If you are passionate about developer experiences, data performance and are a curious problem solver, join us! We are currently hiring for:

* Developer Advocate - https://www.polyscale.ai/careers/developer-advocate

* Software Engineer, Full Stack - React & TypeScript - https://www.polyscale.ai/careers/software-engineer-full-stac...

* Software Engineer, C++ Backend Proxy - https://www.polyscale.ai/careers/software-engineer-backend

* Product Marketing - spec coming soon.

That’s right. Currently the auto invalidation is somewhat of a blunt instrument in that it will blow away all cache data related to the table(s) as default. That approach favors consistency over performance, but is also a natural fit to some query traffic patterns. You can also switch it off if you so desire. The next iteration that is imminent for release can be much more surgical, invalidating based on more of the query details.

Connection pooling docs are coming soon as part of the feature early access launch. Feel free to drop me an email and I can let you know when its released. Im ben at our domain.

We're building PolyScale[1] to address this problem. PolyScale is a serverless edge cache for databases so you can easily distribute your reads.

We are opening up early access to our connection pooling features in the next couple of weeks which allows FaaS platforms like Netlify, Cloudflare etc to create large numbers of ephemeral connections, without impacting your origin database, as well as reducing connection latency significantly.

[1] https://www.polyscale.ai/