There were 2 emails sent, you must have seen the screenshot from the first one only.
The second one was notification that they would be charging our "prepaid accounts" the next day (Saturday Sept 17) for the next month's services. It was very much more of an invoice (breaking down what they would charge us for) than the first email.
If anyone did have a credit card attached to their account, they're looking at it from the fraud angle. Everyone else is wondering if they're going to try to force some kind of debt collection because we are not going to pay, that's likely where the knives-out reactions are coming from.
Doing an automatic in-place "upgrade" from a free tier to a paid account tier to years-old accounts (and without customer consent!) is a scummy move. Even if not intended to be malicious, it's an idiotic thing to do, especially business-wise. They just flushed away any good will leftover from their acquisition of the FogBugz name.
The cherry on top is that any attempt to log into the account to cancel it, or to contact customer services (which requires creating a customer service account) errors out, so any of the legitimate ways one might think of using to address the situation are blocked.
The purpose of a license is to grant rights under conditions to those who would otherwise have no rights to use or modify the software at all.
As the copyright owner, you already have full rights to use the code you wrote the way you want, so you do not need to enter a license agreement with yourself to gain rights that you already have. And so you are not subjected to the license; the license is between you as the copyright owner granting rights to others who are NOT the copyright owner.
As far as public contributions to the GPL'd code (such as Neo4j Community Edition), usually there are agreements that are made (contributor license agreements or copyright transfer agreements) prior to merging the contributed code that resolve issues of relicensing and usage.
This answer on StackExchange provides some good detail.
I wouldn't say relational databases are poorly designed, any more than saying a hammer is poorly designed because it makes for a bad screwdriver. A hammer is still excellent at working with nails, it's hard to find a better tool to work with that. This is just about using the right tool for the job.
Back when data was simpler and not as big, relational databases were perfect, and there have been years of engineering and bug fixes that have gone into them. They are excellent at what they do, and they continue to improve.
But as technology has improved, as our disks and memory have gotten bigger, as the data we collect and want to query over has gotten bigger, and as our queries have gotten more complex, we've been running against the limitations of log(n) joins and relational database technology for some use cases. Now, not every problem is a nail. Some are screws. Some are more exotic.
That's been the reason for nosql databases in the first place, to try to address the shortcomings that arise as data gets bigger, more complex, and as queries and operations become more complex over large data.
log(n) joins are fine...until data explodes, and you're no longer doing just a handful of joins per query, but a very large number of them, maybe even unbounded, and maybe the rules for what data to traverse has soft or even no restrictions. When your data is graphy, when the questions you want to answer require traversals of this scale and nature, and when you want to make sure your traversal costs are proportional only to the graph you want to traverse (and not proportional to the total data in the database), then graph databases provide a very good tool for modeling and efficiently querying over that data.
Graph databases are relatively young, compared to relational databases. Yet their usage has been proven, especially as more graphy problems and data have grown more common.
Relational databases are still useful, and still improving, and graph databases will also continue to grow and improve side by side with them.
We even have a GQL initiative, on the language side, aimed at becoming an ISO standard that will hold an equivalent position as SQL, but for graph querying. That should speak to the value and importance of the paradigm.
To propose a different perspective, a relationship in a graph db is like a materialized join. You pay on relationship creation (you might be using index lookups to find the nodes to connect, similar to a relational db), then for traversal it's just pointer hopping across the relationships to the connected nodes. Aside from the initial lookup of starting node(s), traversing the graph won't use indexes at all, so becomes constant time operations.
If that were so then there would be no need for native graph databases at all, and we would not be seeing cases that could not be served by relational dbs that are possible with Neo4j and native graphs.
You may be thinking of non-graph use cases. When hundreds of thousands to millions or more traversals are required to address graphy use cases, if those traversals are implemented as table joins, and the join complexity is dependent upon tables that are millions or billions in size (so dependence on total size of the data instead of just the relevant connected relationships) then you can see where pointer hopping on only relevant connected relationship and node records (proportional only to the elements of the subgraph traversed, not total data) would outperform the relational model. Also you have the flexibility of being as strict or as lenient as required with the labels of nodes traversed or the relationship types traversed, as well as their direction. That's tougher to do when you may not know what tables are meant to be joined or how, or if you pour all your nodes into a giant table, where the join cost is proportional to your total data.
Relational databases are very good at what they do. But no tool is perfect and covers all use cases easily. Design is a matter of tradeoffs, and some of the design choices made that make them excellent in many categories becomes a weakness in others. We're in an era of big data, huge data, where modeling, traversing, and exploring the connections within this data is increasingly valuable, and increasingly costly due to the sheer amount of data and the complexity of both the connections between and the use cases themselves. Native graph databases are a tool for these cases, and can also bring along simplicity in modeling and querying to the table as well as the performance that gives them an edge in these cases.
Hello, just making sure you're aware that while the Neo4j Sandbox is a quick way to get a feel for Neo4j and try out some tutorials and datasets, it isn't meant to be used as a general Neo4j cloud service. Your sandbox gets wiped after 10 days, for example, and the resources supporting sandbox instances aren't optimized for performance. It's a casual try-it-out experience.
The Sandbox also predates Aura (our ACTUAL cloud service) by a number of years, so you could say the sandbox is kind of like a prototype.
The second one was notification that they would be charging our "prepaid accounts" the next day (Saturday Sept 17) for the next month's services. It was very much more of an invoice (breaking down what they would charge us for) than the first email.
If anyone did have a credit card attached to their account, they're looking at it from the fraud angle. Everyone else is wondering if they're going to try to force some kind of debt collection because we are not going to pay, that's likely where the knives-out reactions are coming from.
Doing an automatic in-place "upgrade" from a free tier to a paid account tier to years-old accounts (and without customer consent!) is a scummy move. Even if not intended to be malicious, it's an idiotic thing to do, especially business-wise. They just flushed away any good will leftover from their acquisition of the FogBugz name.
The cherry on top is that any attempt to log into the account to cancel it, or to contact customer services (which requires creating a customer service account) errors out, so any of the legitimate ways one might think of using to address the situation are blocked.