What do you like best about Aiven for PostgreSQL?
The service is simple and easy to use. It is easy to spin up a Postgres instance in Aiven's cloud service via the UI or infrastructure-as-code tooling (such as Terraform) and have this operate alongside our existing cloud infrastructure in a private VPC with no shared access to the internet.
The functionality for enterprise usage of the services has improved markedly in recent months, with facilities for shared group control of an account and centralised billing accounts, just like the big three cloud providers. I have confidence that my data is hosted in a secure facility by a team of experts who understand deeply the systems they are integrated with. The console also surprises me with features I didn't know existed; today I found out Aiven is ahead of the curve by offering SAML authentication as standard. Way to go for not requiring an "enterprise" pricing plan for such essential functionality!
Running services via Aiven is by no means the cheapest option when considering the raw hardware/cloud instance costs, but after taking into account the operational and opportunity costs of running our own database services, it's competitive. Review collected by and hosted on G2.com.
What do you dislike about Aiven for PostgreSQL?
There are areas for Aiven to improve around data residency/governance and the feeling I get regarding the safety of my data when using Aiven's services. I would also like to see developments in Aiven's technical approach to managing the services to instil more confidence that this service will adequately safeguard my data.
1. Currently, Aiven services are hosted inside Aiven's cloud provider account, not a cloud account of my own. I do not however understand how our data are safeguarded in the event Aiven were to cease trading or a compromised actor inside Aiven were to gain access to and/or manipulate our data. While Aiven has appropriate audited ISO and SoC attestations, such process-based controls are not the same as hard limits on the ability for a bad actor to move laterally in the event they maliciously gained access as a privileged user to your cloud account. This gives me residual concern regarding the use of Aiven's services and consideration regarding protecting the data by making my own backups outside Aiven.
2. I would like the ability to "bring your own cloud" as standard, for all of Aiven's services. This would take the form of sharing access via a cloud provider's native IAM credentials to a project and binding the appropriate IAM permissions to enable Aiven to spin up and manage its own instances in the project. While this is a function available once usage crosses a higher monthly commit with Aiven, Postgres is actually really efficient and so it will take a long time for even a widely-used, highly-scaled service to reach this threshold.
Offering a bring your own cloud service as standard would resolve many of the concerns around point #1 regarding data ownership, because I would have assurance that my data are stored in cloud infrastructure attached to my own billing account. This reassurance is essential in all cases, but especially so in regulated industries.
As a product feature, Aiven could subsequently offer "cloud-provider security protection" by having its managed services offer to make a backup from the user's production instances in their own cloud into storage buckets in Aiven's cloud accounts (held under Aiven's separate billing). This would offer customers peace of mind that their data are safely streamed out to another organisation's cloud account and thus there is redundancy in the event their own cloud account should be accidentally compromised or lost for some reason.
Furthermore, Aiven should provide direct access to the write-ahead logs.
3. Further to data backups, there is very minimal insight into the controls Aiven has in place around these. Aiven has great backup functionality including point-in-time restores, but to have confidence that they are usable, I need to know they are resilient to various erroneous (even byzantine) conditions in which a user might need to resort to them. Once again, process-based controls are useful for managing risk, but there is always a residual risk which cannot be discharged in Aiven hosting large quantities of user data and thus being a singularly unique target to attack with potentially widespread ramifications for more than just Aiven's own business.
4. Aiven's topology for Google Cloud Platform appears to place all instances and VPCs into a single project on Aiven's side. Is this scalable? How are risks handled here?
5. The console has a number of bugs which introduce operational hazards. For example, the bug when attempting to activate a project in the project selector which the user can see (it is part of a centralised account) but for which permissions have not propagated, thus they do not have permission to inspect inside the project. Rather than present an appropriate "Permission denied" error which interrupts the user's workflow, the project selector will instead silently jump to the next project which the user does have permissions to access. This is very dangerous because it means a user who believed they were accessing a development project, perhaps to remove some infrastructure, can be connected instead to a production project and inadvertently delete the wrong instance! Good operational practices in verifying the project prior to destructive operations are good here, but such bugs do not instil confidence as to other bugs which may exist in the console. I have reported this to product support so I hope it can be rectified soon.
6. Aiven's support staff are great! You should definitely reach out to them. However, it's not clear what the SLA around support is, or how I might upgrade this if I needed a tighter SLA on the services I take from them. Review collected by and hosted on G2.com.
