4 ms·

To verify that you first have define "small". I've seen a large postgres db handling what I could call a large amount of data, and in a separate situation seen

To verify that you first have define "small". I've seen a large postgres db handling what I could call a large amount of data, and in a separate situation seen it scaled horizontally through sharding to an even larger scale. Premature abstractions cause pain

nyrikki 2y ago
When your product depends on OLAP is a good indicator, SQL has always been bad at Analysis. But by 'small' I was talking about code complexity and maintainability, not DB size. "Premature abstractions" is typically about avoiding being to DRY, not to preventing yourself from marrying a DBMS that you haven't even dated yet for the remainder of your products life. Note what they called out on their blog. > MySQL RDS does not horizontally scale through, for example, partitioning by itself. Therefore we doubled the RDS instance size every time we required more storage. > Maintaining such a RDS required significantly more engineering efforts than we expected. For example, the database was initially shared with other critical features and any downtime could cause severe impacts to those functionalities. > Our next step was to move the rest of the data to DynamoDB, which would require rewriting the majority of the code. After evaluating the pros and cons, we decided not to proceed in this direction. Whenever you have a vendor, no matter if the product is free or ...Oracle, de-risking future unknowns with an abstraction is something to consider. You don't know what your future needs, what that external entity will do, or if the product fits your needs. You can choose to kick the can down the road and pray, or you can spend the extra 5 minutes of a red-green-refactor cycle to do something as simple as dependency inversion, persistence ignorance or what ever gives you a two way door. Typically abstracting your DBMS has early pay offs that are worth it even without the above, like not needing to instantiate a database to do testing of business logic. The issues with RDBMS barriers to exit and conversion costs have been known for a very very long time. As an example: NBS Special Publication 500-84 (1981) https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nbsspecialpublication500-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nbsspecialpublic... > 4.5»4 Portability. The final important cost of a DBMS is its lack of portability. Only a few commercially available systems run on more than one kind of equipment, and agencies that want to change hardware may find that they are unable to do so without also changing their DBMS. One of the managers we interviewed decided to continue with the same DBMS in order to avoid conversion costs for existing applications. As a result his hardware procurement was limited to a major vendor and some smaller companies that sell "plug compatible" computers. Any agency that uses a DBMS extensively must recognize that its investment in application programs represents a commitment to a particular DBMS and, in many cases, to a particular hardware vendor.

nyrikki 2y ago

When your product depends on OLAP is a good indicator, SQL has always been bad at Analysis. But by 'small' I was talking about code complexity and maintainability, not DB size. "Premature abstractions" is typically about avoiding being to DRY, not to preventing yourself from marrying a DBMS that you haven't even dated yet for the remainder of your products life. Note what they called out on their blog. > MySQL RDS does not horizontally scale through, for example, partitioning by itself. Therefore we doubled the RDS instance size every time we required more storage. > Maintaining such a RDS required significantly more engineering efforts than we expected. For example, the database was initially shared with other critical features and any downtime could cause severe impacts to those functionalities. > Our next step was to move the rest of the data to DynamoDB, which would require rewriting the majority of the code. After evaluating the pros and cons, we decided not to proceed in this direction. Whenever you have a vendor, no matter if the product is free or ...Oracle, de-risking future unknowns with an abstraction is something to consider. You don't know what your future needs, what that external entity will do, or if the product fits your needs. You can choose to kick the can down the road and pray, or you can spend the extra 5 minutes of a red-green-refactor cycle to do something as simple as dependency inversion, persistence ignorance or what ever gives you a two way door. Typically abstracting your DBMS has early pay offs that are worth it even without the above, like not needing to instantiate a database to do testing of business logic. The issues with RDBMS barriers to exit and conversion costs have been known for a very very long time. As an example: NBS Special Publication 500-84 (1981) https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nbsspecialpublication500-84.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nbsspecialpublic... > 4.5»4 Portability. The final important cost of a DBMS is its lack of portability. Only a few commercially available systems run on more than one kind of equipment, and agencies that want to change hardware may find that they are unable to do so without also changing their DBMS. One of the managers we interviewed decided to continue with the same DBMS in order to avoid conversion costs for existing applications. As a result his hardware procurement was limited to a major vendor and some smaller companies that sell "plug compatible" computers. Any agency that uses a DBMS extensively must recognize that its investment in application programs represents a commitment to a particular DBMS and, in many cases, to a particular hardware vendor.