Ambily KK

Here are the latest backend web framework performance benchmark test results in a scenario of a single GET REST API Endpoint returning data from a single PostgreSQL function. I have created an interactive chart web page for easier results analysis. Here are some of my conclusions and observations: 1) Do not parse test results while drinking! 2) .NET9 is really not that optimized compared.NET8, as I was led previously to believe. 3) When we ask which backend web framework is the fastest, we should first ask how many concurrent users there are and what the average response size is. Not all web frameworks behave the same in different environments. 4) RUST and GO are not suitable for this type of application. They may shine in system programming and low-level work, but when it comes to returning responses from a web server, it's anything but these two. 5) Having said that, these performances depend largely on a web server's performances, not on your language implementation. 6) I'm not as good at optimization as I thought I was; there is so much to learn yet. 7) If you want the best possible web performance, choose good old PHP on the Swoole server. 8) If you want a low-code platform for rapid development, use PostgREST, Omnigres, or NpgsqlRest. 9) FastAPI and Fastify are not that fast. It's just marketing. That's all I have for you. Anything but GO or RUST for this type of work. Bye.

10

1 Comment

Check out the latest blog post from Sajeetharan Sinnathurai about the #MSBuild announcement, " Announcing General Availability of #AzureCosmosDB Integration with Vercel" https://lnkd.in/er3x62K9

2

#patterns Hitting message size limit in messaging systems like Azure Storage Queue then try Cliam-Check pattern. In this pattern, actual message is stored in blob container while a reference token to that message is stored in Queue. Reference - https://lnkd.in/gntWkfTA

4

Postgres 17 Highlights as shared by ENTERPRISEDB SOFTWARE INDIA PRIVATE LIMITED > Performance enhancements (improved btree and vacuum memory management) > New JSON capabilities (including the long-awaited JSON_TABLE() function!) > Logical replication improvements > Support for block-level incremental backups in pg_basebackups (Barman's ready to roll with this!) > COPY command now has an "ON ERROR ignore" option (data importers, rejoice!) > Enhanced MERGE capabilities Check out these resources to deepen your Postgres 17 knowledge: > Official Postgres 17 release notes ( https://lnkd.in/g7keM2Gc ) > EDB's Postgres 17 communication ( https://lnkd.in/gpcZ-4J6 ) > General overview from Tom Kincaid, SVP Engineering Servers & Tools ( https://lnkd.in/gERsjZUp ) > Detailed insights from major contributor Amit Kapila (https://lnkd.in/gi7_q9s8) > New MERGE capabilities explained by SQL expert Markus Winand (https://lnkd.in/gnreUGwW) > Logical replication enhancements breakdown by Amit Kapila (https://lnkd.in/gtvKJKQD) > Performance benchmarks by Crunchy Data (https://lnkd.in/gNxnpN6g) > Seven-part blog series on Postgres 17 features by Deepak Mahto pl/pgsql new features (https://lnkd.in/g6Ad_kAY nulls constraint (https://lnkd.in/guM7NCwq) > COPY (https://lnkd.in/gWPQf4Br) > MERGE (https://lnkd.in/gYTsU6Bf) > Correlated queries (https://lnkd.in/gKqjCE6X) > Loggin event triggers (https://lnkd.in/g8etWeuu) (I know some customers asked for this feature) > pg_maintain (https://lnkd.in/gF2uwGsk)

15

This Blog gives you an overview of using Azure Data Factory to load JSON Blob from Azure Storage and load it into Azure SQL https://lnkd.in/g5M8RxEt

23

✨ Exciting update for #AzureCosmosDB users! The Private Preview for read and read-write privileges in secondary regions is now live! Reduce latency and optimize your operations with this feature. 🔗 https://lnkd.in/e6x-KZSG

1

Airflow on AKS: A Step-by-Step Guide to Helm Deployment on Azure #WorkSmartWithK8s #kubernetes #aks #airflow #terraform #helm #stepbystepguide https://lnkd.in/eFAXWN7k

31

1 Comment

Explore the preallocation pattern to optimize performance and resource utilization by preallocating resources like document IDs in #AzureCosmosDB. Learn more in this blog post: https://lnkd.in/e-GNy9MR #Azure

2

In the second part of the Graph Stuff for Members, we'll take a look at some of the more advanced use cases with Graph Explorer. https://lnkd.in/eyMtRZJv #intune #autopilot #microsoftgraph #windows11 #azure #entraid #surfaceforbusiness #migration #microsoft365 #msftadvocate

10

1 Comment

Explore messaging and streaming platforms using cloudnative microservices with Devprime platform accelerators and stack Try it free: 🚀🚀🚀 https://devprime.io #devprime #cloudnative #microservices #csharp #dotnet #vscode #visualstudio #dx #developerpeoductivity #startup #startupinvestment #startupfunding #startupfounder

8

The Architect’s Guide to Open Table Formats and Object Storage https://lnkd.in/gfTxqiYr Open table formats and object storage are redefining how organizations architect their data systems, providing the foundation for scalable, efficient and future-proof data lakehouses. By leveraging the unique strengths of object storage — its scalability, flexibility and cost-effectiveness — alongside the advanced metadata management capabilities of open table formats like Apache Iceberg, Delta Lake and Apache Hudi, organizations can create modular architectures that meet the demands of modern data workloads. At the core of this architectural shift is the disaggregation of compute and storage. Object storage serves as the foundation, offering seamless management of structured, semi-structured and unstructured data, while open table formats act as a metadata abstraction layer, enabling database-like features such as schemas, partitions and ACID (atomicity, consistency, isolation and durability) transactions. Compute engines like Spark, Presto, Trino and Dremio interact with these table formats, delivering the flexibility to process and analyze data at scale without vendor lock-in. This guide will delve into the role of open table formats and object storage in building modern data lakehouses. I’ll explore their evolution, compare leading table formats and highlight performance considerations that optimize your architecture for advanced analytics and AI workloads. By understanding these components, you’ll be equipped to design data systems that are not only efficient and scalable but also adaptable to the rapidly changing demands of the data-driven era. Where Open Table Formats Fit In The modern data lakehouse architecture builds upon three critical components: the storage layer, the open table format and the compute engines. This modular design is optimized to take full advantage of object storage’s scalability and cost-efficiency while leveraging open table formats for seamless metadata management and interoperability across diverse compute engines. At its foundation lies the storage layer of object storage, which provides scalable and flexible storage for structured, semi-structured and unstructured data. In the storage layer sit the open table formats, which could be Apache Iceberg, Delta Lake or Apache Hudi. These open table formats act as a metadata abstraction layer, providing database-like features including schemas, partitions and versioning as well as advanced features like ACID transactions, schema evolution and time travel. Finally, compute engines like Spark, Presto, Trino and Dremio interact with the open table formats to process and analyze data at scale, offering users the flexibility to choose the best tool for their workload. Evolution of Data Architectures The rise of data lakehouses can be understood as part of the broader evolution of data architectures. Early systems like online transaction processing (OTLP) databases...

1

🔧 Fine-tune your #AzureCosmosDB for #MongoDB queries with vCore indexing! From compound indexes to wildcard support, explore all the features that make querying data efficient and effective. 🌟 https://lnkd.in/etUKe_yz

3

Learn best practices for transitioning a graph workload to Azure Cosmos DB for NoSQL, based on real-world experience. Key strategies include efficient data modeling and migration to optimize performance and scalability. https://lnkd.in/e3YfzfNc

4

Partitioned tables can help parallelize queries across multiple threads and generally improve performance when used in the right context. Read the full blog: https://lnkd.in/gfwq43vU #Deephaven #LiveDataframes #BigData

6