Best of NoSQL — August 2024

1. 1
   Article

   Hacker News·2y

   Just use Postgres

   When developing a new application requiring persistent data storage, Postgres should be the default choice, especially for web applications. SQLite is suitable for desktop or mobile apps but not ideal for websites. NoSQL databases like DynamoDB, MongoDB, Cassandra, and others offer performance benefits if the access patterns are well-defined beforehand but are less flexible when handling evolving access needs. Redis is efficient for caching but can be used as a primary database with some trade-offs. Datomic and XTDB present innovative approaches with specific benefits and challenges. While advanced databases like Kafka and ElasticSearch excel in niche tasks, Postgres often suffices for general needs, potentially complemented by simpler built-in search functions.

   62

   13
2. 2
   Article

   Metadata·2y

   Designing Data Intensive Applications Book

   The post discusses the book 'Designing Data Intensive Applications' as part of a book club, focusing on the first two chapters which cover reliability, scalability, and maintainability of applications, as well as different data models and query languages. It explains the historical context and comparisons between relational and document databases, including the benefits and drawbacks of each model, and the impact of these choices on application design.

   36

   1
3. 3
   Article

   Medium·2y

   Embracing Simplicity and Composability in Data Engineering

   The post highlights the importance of simplicity and composability in data engineering, drawing lessons from decades of industry experience. It discusses the Unix philosophy of treating data as files, the evolution of databases and NoSQL, and the complexity introduced by new ecosystems like Hadoop and Kubernetes. The post also critiques the over-complication of agile methodologies and stresses the necessity of adhering to fundamental principles to maintain flexibility and long-term value in software systems.

   24
4. 4
   Article

   ByteByteGo·2y

   Counting Billions of Content Usage at Canva

   Canva faced significant challenges in accurately counting content usage for their Creators Program due to the rapidly growing data volume which was originally handled by a MySQL-based system. The MySQL design, while simple, created scalability issues. Canva explored transitioning to DynamoDB but found it wouldn't solve their processing problems. Ultimately, they moved to an OLAP-based solution with Snowflake, significantly improving latency and handling billions of records efficiently. The new architecture provided numerous benefits including reduced latency, simplified incident handling, and decreased data storage needs, though it also introduced some new complexities in data transformation and infrastructure management.

   20