March 2024 Summaries

PostgreSQL's partitioning and LockManager limitations can lead to scalability issues, particularly when querying large tables with many partitions. In contrast, YugabyteDB offers distributed tables, indexes, and linear scalability, making it an attractive option for scaling PostgreSQL applications without changing the application code. By leveraging automatic sharding or YSQL declarative partitioning, developers can simplify operations and improve execution performance, while avoiding the limitations of PostgreSQL's lock manager contention.

YugabyteDB is designed for high availability and fault tolerance, enabling it to survive failures across fault domains such as racks. It achieves this by replicating data across three fault domains, known as a replication factor of 3, which ensures that the cluster remains operational even if one or more racks go offline. By treating racks as virtual zones, YugabyteDB automatically handles rack failures and provides zone-level resilience. This setup allows for easy deployment and management of clusters in on-premises data centers, ensuring high availability and fault tolerance.

PostgreSQL is a relational database designed for single-server deployments, lacking capabilities of a distributed database. To scale PostgreSQL, consider evolving to a robust, distributed deployment that provides resilience and global scale by adopting one of three forms: Multi-Master Asynchronous Replication, Multi-Master Sharded PostgreSQL with a Coordinator, or Multi-Master Shared-Nothing PostgreSQL. A complete guide to distributed PostgreSQL is available for download, offering insights into strengths, weaknesses, use cases, and potential challenges.

YugabyteDB has achieved PCI DSS Level 1 compliance for its fully managed DBaaS offering, demonstrating a commitment to delivering strong performance while maintaining sensitive data security. This is the highest level of assurance provided by the Payment Card Industry Data Security Standard (PCI DSS), affirming Yugabyte's dedication to protecting customer data and building trust with customers and partners. Achieving PCI DSS compliance strengthens Yugabyte's existing portfolio of security certifications and attestations, providing benefits such as data breach prevention, enhanced customer trust, avoidance of fines and penalties, and alignment with global data security standards. This achievement demonstrates Yugabyte's commitment to securing mission-critical workloads and provides unparalleled services to its customers.

Multi-tenancy is a common strategy among Independent Software Vendors (ISVs), enterprises providing database-as-a-service (DBaaS) to different business units, or firms creating sandboxes for development and testing. It allows a single instance of an app and its infrastructure to serve multiple customers, with users sharing both the application and the database, but their data remaining isolated and invisible to others. Companies developing fully-managed SaaS solutions as replacements for traditional self-managed ones have brought multi-tenancy to the forefront, prompting discussions on when to use what approach. There are five (and a half) strategies that can be used to manage multi-tenancy: separating tenants by row, schema, database, table partition, and cluster. Each strategy has its benefits and challenges, and companies should consider their specific needs and requirements before choosing the best approach for their multi-tenant application. Separating tenants by row is suitable for achieving the lowest management overhead when onboarding new tenants, simplifying access controls, running a single application version for all tenants, and navigating complex backup and recovery per tenant. Separating tenants by schema makes sense in scenarios requiring high data isolation between tenants, customizable schemas, combining data across tenants, or taking on additional maintenance activities across tenants. Managing application releases simultaneously for all tenants while controlling the data placement is achieved through separating tenants by table partition. This approach is suitable for large numbers of tenants with varying data separation needs, flexibility in managing application releases, and controlling data placement per tenant. The primary goal is to achieve the lowest possible management overhead, with or without row-level security. A combination of "Separate Tenants by Row (With or Without Row-Level Security)" and "Separate by Database" can be used for a tiered-based tenant approach, leveraging the advantages of each method according to tenant needs. Finally, separating tenants by cluster is suitable for high data volumes and requiring one's own cluster, while smaller tenants can reside on a single cluster.