Hello All, we are in the process of
# spicedb
l
Hello All, we are in the process of putting SpiceDB into out authorization process and I was curious as if i can separate reads from writes. My system will have a lower write rate, which can have bursts of many writes, depending on the situation. We are very much a read heavy system. We can have reads in the thousands per minute. I would like to see if i can separate reads from writes so I can scale them independently. We plan on using EKS in AWS and Aurora Postgres database for now.
v
SpiceDB is horizontally scalable, there is not much to win from having a cluster for reads and another one for writes. However, in your setup id say the challenge comes from scaling Aurora, I'm not super familiar with its architecture to comment atm.
l
Yeah, I know SpiceDB scales great horizontally. My cloud architect was curious to see if we can scale one over the other. It might have to be done at the Aurora Postgres level but for the EKS cluster, we would like to have had SpiceDB separate from reads and writes within its "black box" just so we can scale the different pieces independently. But if we can't scale independently, it isn't a killer but more of an option to make our system perform just that much better.
j
you can have two clusters, one read and one write
so long as they talk to the same datastore
the downside is your client will have to switch which endpoint+token it is using
l
that is good to know. I will pass that on, thank you.
j
you can even mark one as read only
which will prevent write ops from working
v
but to clarify, there is no need from a scaling perspective. the connection pools are separated. The reason folks have used one write cluster and one read cluster is for security reasons.
so to me it sounds like a premature architectural design to separate those, if you ask me, but it can be done, yes
4 Views