Does Fastly still uses Vinyl Cache? Wondering who else is using it as well in production.
Vinyl Cache and Varnish Cache
21–30 of 45 posts
Re: Vinyl Cache and Varnish Cache
#22Earlier quoted context omitted.
To me the biggest "unknown" with Percona is that MariaDB (the company) bought out Codership (the creators of Galera Cluster, which XtraDB Cluster is based on) and it doesn't seem to be OSS any more. I'm sure for some shops this will drive them to pay for the same feature in MariaDB cluster, but I'm more likely to just transition to MySQL Group Replication. This is my whole point about MariaDB - they are steadily maki…
I don't think your last sentence is fair. Many workloads don't need something like Galera, as standard async replication scales to extreme levels, and you can achieve excellent HA with external orchestration and/or proxies. FOSS MariaDB is definitely not toy-scale only. Oracle has also been guilty of locking modern table stakes behind the MySQL Enterprise / Heatwave pay gate, such as vector indexes and JS stored proc…
> Many workloads don't need something like Galera [etc...]
This continues the faulty line of thinking that open source is just for hobby-level projects or early startup throwaway infrastructure. So many open-core models rely on this falsehood to rationalize their decisions. It should be possible to run large-scale important Internet things on Open Source code, too, for a variety of reasons.
Re: Vinyl Cache and Varnish Cache
#23Earlier quoted context omitted.
I don't think your last sentence is fair. Many workloads don't need something like Galera, as standard async replication scales to extreme levels, and you can achieve excellent HA with external orchestration and/or proxies. FOSS MariaDB is definitely not toy-scale only. Oracle has also been guilty of locking modern table stakes behind the MySQL Enterprise / Heatwave pay gate, such as vector indexes and JS stored proc…
> such as vector indexes and JS stored procedures So, the stuff that basically appeals to people chasing the AI dragon, and has zero practical use for 99.999% of developers making real products? > I wish I was joking! I wish I could care even a little bit about such minutiae.
If you've ever had to work with nontrivial procs in MySQL/MariaDB, it's immediately clear how the status quo is deficient there, and why e.g. Postgres's multi-language support is so much better in comparison.
And how is it "minutiae" to be able to figure out "is my database version actually supported"? This is the fourth versioning scheme they've used in less than a decade, that's a bit nuts I think.
Re: Vinyl Cache and Varnish Cache
#24Earlier quoted context omitted.
I don't think your last sentence is fair. Many workloads don't need something like Galera, as standard async replication scales to extreme levels, and you can achieve excellent HA with external orchestration and/or proxies. FOSS MariaDB is definitely not toy-scale only. Oracle has also been guilty of locking modern table stakes behind the MySQL Enterprise / Heatwave pay gate, such as vector indexes and JS stored proc…
> Many workloads don't need something like Galera [etc...] This continues the faulty line of thinking that open source is just for hobby-level projects or early startup throwaway infrastructure. So many open-core models rely on this falsehood to rationalize their decisions. It should be possible to run large-scale important Internet things on Open Source code, too, for a variety of reasons.
> This continues the faulty line of thinking that open source is just for hobby-level projects or early startup throwaway infrastructure.
How so? I don't understand your comment at all. A huge chunk of the world's economy runs on async replication in FOSS MySQL/MariaDB, my whole point was that you literally don't need Galera to do that.
Re: Vinyl Cache and Varnish Cache
#25Earlier quoted context omitted.
> such as vector indexes and JS stored procedures So, the stuff that basically appeals to people chasing the AI dragon, and has zero practical use for 99.999% of developers making real products? > I wish I was joking! I wish I could care even a little bit about such minutiae.
If you've ever had to work with nontrivial procs in MySQL/MariaDB, it's immediately clear how the status quo is deficient there, and why e.g. Postgres's multi-language support is so much better in comparison. And how is it "minutiae" to be able to figure out "is my database version actually supported"? This is the fourth versioning scheme they've used in less than a decade, that's a bit nuts I think.
I would happily write stored procs using the current language support for a decade without pay, before I'd subject myself to putting javascript in a fucking database engine.
> And how is it "minutiae" to be able to figure out "is my database version actually supported"?
Remembering "8.4", "9.7" and ".4" just doesn't seem like a particularly big deal to me. The number* has only changed 3 times in the last 10 years.
Re: Vinyl Cache and Varnish Cache
#26In Canada, we pronounce it Vinyl CachÉE.
Re: Vinyl Cache and Varnish Cache
#27"Vinyl cache" is an interesting name. I wonder what other candidates the maintainers considered? I was secretly hoping they would name it "Veneer Cache" or something similar to "varnish".
How about Shellac Cache
Re: Vinyl Cache and Varnish Cache
#28Earlier quoted context omitted.
If you've ever had to work with nontrivial procs in MySQL/MariaDB, it's immediately clear how the status quo is deficient there, and why e.g. Postgres's multi-language support is so much better in comparison. And how is it "minutiae" to be able to figure out "is my database version actually supported"? This is the fourth versioning scheme they've used in less than a decade, that's a bit nuts I think.
I would happily write stored procs using the current language support for a decade without pay, before I'd subject myself to putting javascript in a fucking database engine. > And how is it "minutiae" to be able to figure out "is my database version actually supported"? Remembering "8.4", "9.7" and " .4" just doesn't seem like a particularly big deal to me. The number* has only changed 3 times in the last 10 years.
I don't like JS either, but lots of people do. And if you're expanding a DB beyond SQL-only, JS is an obvious first choice before adding further languages from there. (The MySQL feature is called "Multilingual Engine Component" and not "JavaScript Engine Component".)
As for the versioning, it's a nightmare for third party vendors like me, because it will absolutely increase the number of companies who are unintentionally running unsupported non-LTS "innovation" releases because they can't keep all these versioning changes straight. The major-version only changed 3 times in the past decade because 8.0 was "evergreen" for most of that time, which was also not a good strategy, yet the most obvious solution (SemVer) is always ignored by Oracle in favor of more confusing alternatives.
Re: Vinyl Cache and Varnish Cache
#29It sounds like Varnish Cache is kind of a distribution of Vinyl Cache. It's based on the FOSS project with its own downstream patches.
On another topic:
> The Varnish Cache FOSS software was initiated and sponsored by the Norvegian newspaper Verdens Gang. They hired a company called “Linpro” to handle the logistics and me to write the code.
> From Linpro grew the company Varnish Software
> IP-Lawyers still insist that Varnish Software owns the Varnish Cache name
Consultants came in a just assumed the IP? It sounds like a pretty complicated cross-border ordeal, but that is still quite a leap.
Re: Vinyl Cache and Varnish Cache
#30It sounds like Varnish Cache is kind of a distribution of Vinyl Cache. It's based on the FOSS project with its own downstream patches. On another topic: > The Varnish Cache FOSS software was initiated and sponsored by the Norvegian newspaper Verdens Gang. They hired a company called “Linpro” to handle the logistics and me to write the code. > From Linpro grew the company Varnish Software > IP-Lawyers still insist tha…
> What is Varnish Cache?
> Varnish Cache is a distribution of the open-source Vinyl Cache project, made for the modern cloud: ready for Kubernetes, with built-in TLS support, and a long-term-support release cadence with extra modules and tooling layered on top.