First of all, and cluster needs more resources.....so, for argument's sake, let's say you have an 8 engine/32GB ASE in SMP. To move that to CE, you will likely need 9-10 engines and 42GB of memory on at least that node......
....now with CE, the nodes don't have to be identical....but if you are expecting similar performance after a failover - then the other node has to be about the same (9-10 engines and 42GB of memory).
Now, the question is would you see degradation. This was discussed in last month's webcast - if I had the link, I would post it - but I think you have to register (retroactively) and then you are emailed the link.
Let's assume we have only one application and a 2 node cluster. There are two use cases:
1 - Active/Passive - 2 node cluster with all the application load on one node
2 - Active/Active - 2 node cluster with different application users on each node
In previous years, we have discussed cluster locking to death....but, suffice it to say that one of the big differences between ASE SMP and ASE CE is that (normally - without SIDB), each lock request in CE involves a network call. BTW - this also is true of IBM DB2 PureScale as well as Oracle RAC. Since a network is the second slowest device in a computer, this can have an impact on your application - we have seen this be as much as 20% with some customers. To avoid this, you can make the database a "Single Instance Database" (SIDB) in ASE CE sp130+ in which all the locks are retained locally - but then it is only accessible from that node (unless it fails over - and then it is only accessible from the other node). Now, there is a downside to this. In normal cluster mode, since the locks are distributed, we are aware of what pages are in 'doubt' in the event of a failure and only have to do recovery on those pages - in other words super fast failover. In SIDB mode, we no longer are aware of this and have to essentially do full database recovery - which thankfully since all the changes in ASE 15.7 sp42+ - it is much faster than it used to be.....
The above is NOT what we are referring to when discussing horizontal scalability. It is simple cluster mechanics. One aspect is that ASE CE uses standard TCP/IP over Ethernet for the CIPC layer - which I personally (caveat) believe is a big source of a lot of the problems. Both Oracle and IBM require RDBM on Infiniband. For ASE CE 16.0, we are planning on implementing RDMA (as was discussed in the webcast) - which I am one (along with a lot of others in engineering I am sure) that is anxious to see if it eliminates a lot of the penalties associated with packet framing and an often grossly untuned Ethernet interface for the CIPC layer.
Use case #2 (Active/Active) is where you *could* see even greater impact. You might not - you might see some gains - but for OLTP, you would likely see some impact. The reason is simple - if you have two users inserting into the same tables on different nodes, the cluster has to do cache synchronization. And more than just the data page. If you look at a single insert on one of your systems, you will see that it likely does about 20-30 LIOs - assuming you have about 5 indexes of ~5-6 levels each. Those 20-30 pages (again) have to be transferred between nodes....over that same sllllooowwww network. And not only the data/index pages....but the log pages (Oracle partitioned their redo log for example). Again - Oracle and IBM do same thing (mostly). One option, however, would be to instead send the insert from the node where the data isn't in cache to the node where it is - a single network call instead (but then likely incurs some overhead of 2PC). This is the sort of stuff that ASE hasn't done (although we did do some early testing around this). For queries, this means sending query fragments to the other nodes and then merging the results - aka Distributed Query Processing - again - something ASE hasn't done - but IBM and Oracle have. This latter use case is almost exclusively a DSS use case - which if you remember, we had IQ and IQ did have DQP....so putting it in ASE was not a priority. Today, same is true - HANA has scale-out - certainly for analytics....
....scaling out OLTP is a bit more fun. For most use cases, it simply won't work with Shared Disk Clusters - because of the cache synchronization and the single shared disk bottleneck. And by OLTP, I mean true OLTP - not running writes on one node and reads on another. I pointed out all the issues with scaling OLTP on the webcast. That doesn't mean you can't get *some* benefit - by partitioning the apps/deconflicting user accesses to minimize cache synchronization, you can definitely get some benefits. But that is a discussion too long for here.
However, all that is why we are positioning ASE/CE for availability/workload management - e.g. the N+1 availability model where you can combine 3 independent ASE's into a single cluster with an addition 4th node as spare and apps would leverage the nodes as they did previously - but you could also move workload around if necessary.