I’m a little confused… etcd is a database… its just not a sql database.
Maybe your just not familiar with etcd itself and your experience is limited to the embedded etcd that sensu provides to make it easy to get started.
Etcd can be run externally as a separate service cluster, and in production scale deployments that’s preferable to relying on the emdedded etcd service sensu provides. The design of etcd includes replication and snapshotting facilities, so I’m a little confused as to your statement. Maybe you mean you want somethng like RDS for etcd as a managed service from your cloud provider that does all the replication and backup configuration for you with sane defaults?
etcd is designed for infrequently changing state in a distributed environment and it works great as a high availability service when run externally. sensu user definitions are exactly the sort of things etcd works great for in distributed environment. Etcd even has a concept of replicators so you can stream changes from one cluster to another…its how sensu commercial federation feature works to get a global control with separate clusters in different regions.
Sensu events however are different than the rest of the config because there is much higher volume of writes and PostgreSQL is really optimized for high event throughput at scale, but it takes more work to tune, and if your using something like rds instead of your own PostgreSQL, you still might not have the control necessary to optimize the PostgreSQL tuning… managed PostgresSQL has trade-offs.
That being said, for a get up and using Sensu for the first time the embedded etcd for everything really drops the learning curve and the configuration requirements. But for production you should really move away from the embedded etcd and use an external etcd… once you stand up an external etcd (and optionally postgres for events) its much easier to autoscale the sensu-backend instances (operating as etcd clients with no embedded etcd) you need to better match the event throughput.