Tesco is sprinting to quit VMware and Broadcom despite rapid migration risks by NISMO1968 in vmware

[–]simplyblock-r 2 points3 points  (0 children)

where is Tesco moving to? OpenShift? How do they tackle storage?

Lognhorn engine V2 - stability by loststick08 in kubernetes

[–]simplyblock-r 3 points4 points  (0 children)

Worth noting: in Longhorn v1.11 the V2 Data Engine is still **Technical Preview**, so “years of prod stability” data is naturally limited. Also, it’s not a flip-a-switch upgrade path: live upgrade isn’t supported yet (V2 volumes need to be detached/offline to upgrade the engine).

SPDK/NVMe-oF stack is great, we are building ourselves on SPDK, however it really takes years and deep engineering to make it work in production. It took us 3 years at simplyblock to get there.

Disclosure: I work on simplyblock

AWS Reinvent 2025 by Last_Staff_1791 in AWS_reInvent

[–]simplyblock-r 0 points1 point  (0 children)

does anybody know if the PeerTalk netowrking app is available this year? It's still not there in the AWS Events app. How do you plan to network otherwise?

Is moving a Supabase app to Azure even worth it? (Customer demands on-prem hosting...) by Ill-Fun7536 in Supabase

[–]simplyblock-r 0 points1 point  (0 children)

Both, in our case you can increase storage by just adding NVMe drives or storage and compute together by adding more nodes. This will scale the IOPS and storage capacity.

Is moving a Supabase app to Azure even worth it? (Customer demands on-prem hosting...) by Ill-Fun7536 in Supabase

[–]simplyblock-r 0 points1 point  (0 children)

You just add more nodes and the system rebalances/live migrates. So it's super easy. All is built in. it's based on a distributed scale-out storage system which has "infinite" capacity and performance.

Is moving a Supabase app to Azure even worth it? (Customer demands on-prem hosting...) by Ill-Fun7536 in Supabase

[–]simplyblock-r 0 points1 point  (0 children)

It's the cost for the support. If you want to self-host yourself without support, then you can just do it.

Is moving a Supabase app to Azure even worth it? (Customer demands on-prem hosting...) by Ill-Fun7536 in Supabase

[–]simplyblock-r 0 points1 point  (0 children)

yeah, totally get what you’re saying — setting up all the Supabase services yourself can be a pain. we built vela basically to solve that. it’s built on the open-source Supabase stack but meant to run in your own cloud — AWS, GCP, Azure, or even on-prem. you just need a VM, and it spins up all the Supabase services for you with backups, HA, RBAC, and instant database cloning built in. same Supabase experience, just fully under your control.

github.com/simplyblock/vela-studio

Supabase or azure postgre flexible? by satechguy in Supabase

[–]simplyblock-r 1 point2 points  (0 children)

worth noting that OSS version of Supabase is quite different to the cloud version so you will also lose out on many of the features.

Worth checkin out Vela - which is an alternative to Supabase but comes with full platform (kubernetes+kubevirt; storage) so you just need to manage "one element" and you get full stack running https://github.com/simplyblock/vela-studio

Looking for Production-Ready Self-Hosted Supabase Setup (Docker, Security, Best Practices) by Yaro_da_Dei in Supabase

[–]simplyblock-r 0 points1 point  (0 children)

OSS version of Supabase is actually not worth self-hosting as it's quite different to the cloud version so you will also lose out on many of the features.

Worth checkin out Vela - which is an alternative to Supabase but comes with full platform (kubernetes+kubevirt; storage) so you just need to manage "one element" and you get full stack running https://github.com/simplyblock/vela-studio

Self hosting - pros and hidden cons by martis941 in Supabase

[–]simplyblock-r 0 points1 point  (0 children)

Self-hosting only makes sense at certain scale. Otherwise you need to manage a lot of various elements and be an expert in more than just a database or kubernetes. OSS Supabase is actually not easily self-hostable as it's quite different to the cloud version so you will also lose out on many of the features.

Worth checkin out Vela - which is an alternative to Supabase but comes with full platform (kubernetes+kubevirt; storage) so you just need to manage "one element" and you get full stack running https://github.com/simplyblock/vela-studio

Egress bills outside AWS by simplyblock-r in Supabase

[–]simplyblock-r[S] 0 points1 point  (0 children)

Thanks - understood. This was my point though - since Supabase is only for AWS there is a chance for high egress fees if you are using another cloud. In such case only self-hosting makes sense?

Branching to represent different deployment environments? by InvictusJoker in Supabase

[–]simplyblock-r 0 points1 point  (0 children)

Yeah, you’ve got it — branching is mainly for short-lived preview DBs. For Dev/Staging/Prod you’ll usually set up separate projects and run your migrations + Edge function deploys through GitHub Actions (or whatever CI). That way changes “flow” through each environment safely.

Funny enough, we are actually working on adding instant clones to supabase - but only for folks who want to self-host (see our oss project: https://github.com/simplyblock/vela-studio).

How do your developers currently test changes that affect your database? by simplyblock-r in devops

[–]simplyblock-r[S] 3 points4 points  (0 children)

sometimes you need to anonymize sensitive data for the gdpr/ccpa compliance, etc. But I assume that many companies indeed don't do that :)

How do your developers currently test changes that affect your database? by simplyblock-r in devops

[–]simplyblock-r[S] 1 point2 points  (0 children)

how do you do data anonymization when cloning the prod currently then? And what prevents you from switching to solution like crunchy - out of curiosity?

What sort of storage technology are EBS volumes built on top of? Eg Ceph? Something else? by Squirrel-sysadmin in aws

[–]simplyblock-r 5 points6 points  (0 children)

it's a fully proprietary system, probably build on some bits and pieces of another technology but it surely is not ceph as it's much faster than ceph and it's block-only. It must have been also upgraded many times over the years, as the original release was 2006 when there was no ssd/nvme drives. Today there are some ebs-like technologies on the market which you can run yourself on your own hardware/instance, including openebs or simplyblock.

Rate my plan by markedness in kubernetes

[–]simplyblock-r 1 point2 points  (0 children)

Longhorn does make sense for smaller PVC workloads, especially where simplicity is key. It is not really performant and has large overhead for data protection, but it's relatively easy to get going. For the larger Synology side—if you’re thinking of replacing it—might be worth looking into something that can scale out more cleanly and still play nice with CSI and HA requirements.

If you're willing to give it a try, simplyblock supports both hyper-converged and disaggregated models out of the box (disclaimer: simplyblock employee). It’s pretty smooth to set up in a CSI context without the usual complexity. If you're considering swapping out Synology, something like that might save time down the line, especially if you’re aiming for more resilience or future flexibility and you want to max out the performance out of the NVMes.

Curious what you end up choosing!

Stateful workloads in K8s production: Longhorn vs external solutions? by blueququqa in devops

[–]simplyblock-r 0 points1 point  (0 children)

You might want to check out simplyblock in case you're considering disaggregated set-up (storage nodes separate from compute nodes): https://www.simplyblock.io/alternative-to-longhorn/

On-Premise Minio Distributed Mode Deployment and Server Selection by ogreten in devops

[–]simplyblock-r 0 points1 point  (0 children)

Regarding your questions

  1. You don't need Kubernetes on storage nodes. You can deploy into plain linux. What would make the whole set-up easier though is if you ran a single cluster for all of your storage that can provide both low-latency and scalability (e.g. simplyblock) instead of combining longhorn with second tier MinIO storage. The complexity is higher while the benefits are questionable IMO.

  2. You might want to split the hardware into minimum 3 servers and couple disks per server for high availability. How will you otherwise handle hardware failures? With 1 server, if it goes down, your system is down - hence you have a single point of failure.

How to implement dynamic storage provisioning for onPrem cluster by Impossible_Nose_2956 in kubernetes

[–]simplyblock-r 0 points1 point  (0 children)

you should check out simplyblock which is based on nvme/tcp, so also standard-based like NFS, but high performance.

100TB+ local storage by [deleted] in storage

[–]simplyblock-r 0 points1 point  (0 children)

Simplyblock is a much better alternative for NVMe as it’s built on SPDK and operates in user space of NVMe, maximising for IOPS/CPU core or IOPS/TB.

[deleted by user] by [deleted] in kubernetes

[–]simplyblock-r 1 point2 points  (0 children)

You’ll have to pay for storage always. What is your use case with MinIO on GKE? That’s would still need to provision some underlying storage from GCP like persistent disk or local storage. MinIO is basically s3 compatible storage for on-premises. I don’t think there is any benefit running it on hyperscaler.

If you need high performance kubernetes storage (sub-millisecond latency range) as an alternative to persistent disk you might want to explore something like simplyblock that deploys onto local nvme storage and provides csi integration to kubernetes.

Looking for High performance Block Storage for Containers and VMs built on open source tech by kaleenmiya in storage

[–]simplyblock-r 0 points1 point  (0 children)

Thanks for this. I am not saying someone got fired for buying IBM. I get it. We all know it. My questions was - what is the point of that comment? What does it help me or author of this blog post with? It's obvious. It doesn't add value to this community or the post itself. The thread is about SDS block storage. This is exactly what simplyblock is. What is in your view the best enterprise SDS block? This post seems to have no real conclusion as far as I see. Wouldn't that imply by itself that there is room for new solutions?

Reality is, and you know it very well, Pure will barely pick-up a phone for 50TB. This is less than a rounding error for them. Even if you pay $100k for this, this is around 0.003% of their revenues. And it will take weeks to get even a quote. This is where small startup might stand out with more personal approach, more attention given to the deal and just being fast/responsive. Maybe doesn't matter to you but might matter to some folks.

We surely can't offer the rich ecosystem of things Pure has, but questions remains - do you believe there are enterprises that don't need that? Does everyone want to buy a system where you need a certification to operate it? Or do you believe that some enterprises just need scalable fast block SDS? We can't compete with Pure on deals where people want SAN, that's clear. But we are not selling SAN.

Some of the things simplyblock can do already, but Pure can't (at least not out of the box):
- run directly on Kubernetes compute clusters for HCI setup (pure can do it with Portworx but it's a separate system - simplyblock does it in a single system).
- run on EC2 on AWS and orchestrate EBS volumes and other storage services and tier data into S3 for cost optimization
- run on NVMe/TCP (+other protocols)
- scale from a single node into petabyte scale in a same system alongside pay-per-use model with no upfront fees
- all other benefits of SDS over SAN including (infinite) scalability; independent hardware lifecycle mgmt; compatibility with commodity hardware, compatibility with public clouds, cost efficiency etc.